Junk e-mail (spam) is an ever-increasing problem on the Internet, continually requiring new solutions. Existing mechanisms used to attack spam use analysis of individual mail delivery transactions such as SMTP (simple mail transfer protocol) analysis, analysis of mail addressing headers (“from,” “to,” “sender,” and others), and analysis of the subject and/or contents of the mail. While these mechanisms are effective to a large extent, spammers have learned how to get past them, and continue to improve their techniques. Popular mechanisms and ideas that currently exist in this area include:                (1) DNS (domain name server) block lists—these are lists of IP addresses of mail agents that are “known” to send spam; receiving mail servers can check these lists and refuse to accept mail from agents that appear there. These are reactive, static lists, which are maintained by spam complaints. They suffer from maintenance difficulty (reputable senders, including major companies and service providers, frequently find themselves on these lists erroneously, and often have trouble getting off them).        (2) SPF (Sender Permitted From or Sender Policy Framework), Sender-ID, CSV (Certified Server Validation), Domain Keys, and related proposals—these are all techniques designed to confirm that the sender of the mail is not trying to lie about its identity. That is, they each define the “sending domain” and provide a mechanism for domains to publish information that allows recipients to determine whether a message that seems to have a specific “sending domain” came from an agent authorized to send mail on that domain's behalf. With sufficient adoption, these can be effective for “white listing” but cannot be used to detect spam. In fact, many spam domains are participating in SPF, presumably hoping that such participation will give them credibility.        
Mechanisms to validate the sending domain of an email message are becoming popular, standardized, and hotly debated. The goals of SPF, Caller-ID, and Sender-ID are basically the same: they are each designed to prevent “spoofing” by making it possible for domain owners to publish a list of valid outgoing email servers. Messages that pass one of these tests can be reliably associated with a domain that participated in the delivery of the message for some value of “reliably” that is the subject of much debate and controversy. “Plausibly” might be a better characterization, as these techniques are meant to be “best effort” validations.
However, this information is not sufficient to filter spam. In addition to knowing a responsible domain, spam filtering requires information about what domains send spam. Most proponents of domain authentication therefore suggest combining domain authentication with reputation services.
SPF lets a domain declare its outgoing e-mail gateways. All mail from that domain “should” pass through those gateways, if the SPF information is correct. If a message passes an SPF check, and we can assume the domain principally does not send spam, then it is safe to pass that mail directly on to a user. But since spammers, too, have registered domains and published SPF records, we cannot assume that mail that passes SPF validation originated from a non-spam domain.
Therefore, there is a need for a method and system that analyzes email elements that are beyond the control of spammers and overcome the above shortcomings.